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[57] ABSTRACT 

A distributed computer system incorporating multiple com- 
puter processes enables a client computer process to request 
execution of a remote procedure on a server computer 
process even when the server computer process does not 
support a current version of the client computer process. A 
version map is utilized by the client computer process while 
requesting a remote procedure to format the request to a 
version supported by the server computer process, thus 
permitting client and server computer processes coresident 
in a distributed computer system to be upgraded indepen- 
dently while ensuring backward-compatibility with earlier 
versions. 
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/* Test interface. Version 1.0 */ 

interface testint version(l:0) 

{ 

/* User information structure */ 
struct userStruct { 

ucchar userl201; 

int uid; 

char cornmentilOOl ; 
}; 

getUser(svrname ServerName, 
in int uld, 

out struct userStruct *userData); 

setUser(svrname ServerName, 

in struct userStruct userData); 

getUIDfromName(svrnanie ServerName, 
in char 'user, 
out int *uid); 

ge tNamef romU I D ( sv rname Se rve rName , 
in int uid, 
out char *naine); 

} 



FIG. 3 
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/• Test Interface. Version 1.0 ♦/ 

interface testlnt version(l:0) 

{ 

/* User information structure */ 
struct userStruct { 

ucchar user 1201) 

Int uld! 

char comment 1100 1; 
}•' 

getUser(svrname ServerName, 
in int uld, 

out struct userStruct •userData); 

setUser(svrname ServerName. 

in struct userStruct userData); 

getU 1 Df romName ( sv rname Se rve rName . 

in char "user, 
out int 'uld); 

getNamef romU 1 D ( sv rname Se rve rName , 
in int uld, 
out char *name); 

} 

y 

A 



FIG. 4A 
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A 

A 

^»»«»»»*«»«« •**•»••*••«««•«*«»»*«•««»»•«**••* ^ 

/• Test Interface. Version 2.0 */ 

interface testint version(2:0) 

/* User Information structure */ 
struct userStruct { 

ucchar usert30J; /• User is now 30 characters */ 

int uid; 

char comment 1 1001; 
}? 

getUserCsvrname ServerName, 
in int uid* 

out struct userStruct "userData) 
versionmapd.O BYNAME); 

setUser(svrname ServerName, 

in struct userStruct userData) 
versionmapd.O BYNAME); 

getUIDfromNameCsvrname ServerName, 
in char "user, 
out int "uid) 
versionmapd.O DIRECT); 

getN amef r omU I D ( sv r name Se rve rName , 
in int uid, 
out char "name) 
versionmapd.O DIRECT); 

testUID(svrname ServerName, /* Now function "/ 
in int uid); 
versionmapd.O MapTestUidProc); 



FIG. 4B 
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REMOTE PROCEDURE INTERFACE WITH These implementations are thus not capable of handling 

SUPPORT FOR MULTIPLE VERSIONS the situatioD of when a client is upgraded to a new version 

of an interface before a server. Furthermore, this situation is 

FIELD OF THE INVENTION exacerbated in the situation where computer processes func- 
The invention generally relates to distributed computer ^ tion as both clients and servers, where conventional imple- 

systems, and in particular, relates to supporting multiple mentations would require aU processes to be upgraded at the 

versions of client and server computer processes existing in ^^^^ 

distributed computer systems. Therefore, a substantial need has arisen for a manner of 

supporting multiple versions of a remote procedure interface 
BACKGROUND OF THE INVENTION lo in a distributed computer system, which permits both clients 

Distributed computer systems have become more wide- and servers to seamlessly support multiple versions coex- 

spread as interconnected computer networks and the like isting within the system. 

have proliferated. Distributed computer systems are charac- ^„ ,^.™^.t 

terized by the sharing of resources and the use of multiple SUMMARY OF THE INVENTION 

computer "processes" running on multiple computer sys- The invention addressees these and other problems asso- 

tems to cooperatively perform tasks, where computer "pro- ciated with the prior art in providing an extended remote 

cesses" are routines or threads running or executing on procedure interface which maps each remote procedure 

computer systems, e.g., as part of larger applications or defined in the interface to prior versions of the remote 

programs. Distributed operating principles may be found, procedure. This enables client computer processes to utilize 

for example, on Local Area Networks (LAN's), Wide Area a version map from the interface when requesting execution 

Networks (WAN's), and on global distributed networks such of remote procedures so that the requests are in formats 

as the Internet. supported by the server computer processes executing the 

One way in which multiple computer processes may remote procedures, regardless of the versions of the remote 

cooperatively perform tasks is under a "client-server" rcla- procedure interface in the client and server processes. This 

tionship. In such a relationship, a "client" or calling com- is in direct contrast to conventional systems, as the preferred 

puter process issues or sends a request for a remote proce- remote procedure interfaces enable clients, and not just 

dure to a "server" or receiving computer process which servers, to support multiple versions of an interface, 

executes the procedure. It will be appreciated that while one By mapping remote procedures to prior versions of the 

computer process may function as a client when it issues a same, the manner or order in which clients and servers are 

procedure request and another may function as a server upgraded in a distributed computer system are no longer 

when it executes the procedure, any computer process may critical, which is particularly beneficial in shared and public 

function as both a client and a server in different capacities. network environments where control over interface versions 

A preferred manner of passing remote procedure requests is all but impossible. Moreover, as remote procedure inter- 
between clients and servers is through Remote Procedure faces and distributed computing applications are enhanced 
Calls (RPC*s), which are typically defined using a remote and additional versions are supported, new applications may 
procedure interface, e.g., using a specific Interface Defini- be implemented with less effort and with greater backward 
tion Language (IDL). IDL's have been developed, for compatibility and seamless integration into existing systems, 
example, for the Open Systems Foundation Distributed Further, often much of the underlying code can still remain 
Computing Environment (OSF DCE), the Windows 95 and the same, thereby freeing the interface from particular 
Windows NT operating systems, the UNIX operating computer architectures and making the interface less 
system, and the Sun Network File System (NFS), among platform-dependent. 

others. Therefore, in accordance with one aspect of the invention 

As new functionality is implemented in computer pro- a computer system is provided comprising a client computer 
cesses and environments, however, remote procedure inter- 45 process for requesting a remote procedure to be executed by 

faces often may be enhanced to support the new function- a server computer process external to the client computer 

aUty. As is common in the industry, enhancements to a process. The client computer process supports a first version 

remote procedure interface, like any computer program or of the remote procedure and the server computer process 

application, are embodied in a new "version" of the inter- supports a second version of the remote procedure. The 
face. 50 client computer process includes a mapper that maps the first 

To support a new version of a remote procedure interface, version of the remote procedure to the second version of the 

both the client and server utilizing the interface must support remote procedure if the server computer process does not 

the new version. In many distributed computer systems, support the first version of the remote procedure; and a 

however, it is impossible or impractical to upgrade all clients requester, coupled to the mapper, that requests the server 
and servers at the same time to a new version of a remote 55 computer process to execute the second version of the 

procedure interface. This may be due to cost constraints remote procedure. 

(e.g., in internal networks) or due to lack of control (e.g., in According to an additional aspect of the invention, a 

shared or public networks). Consequently, multiple versions distributed computer system is provided, which includes 

of an interface may exist over a network. first and second computer systems coupled through a net- 
The only manner used heretofore to handle multiple 60 work; a remote procedure interface residing in the first 

interface versions is to allow servers to support multiple computer system, the remote procedure interface defining a 

versions, with clients supporting only single versions. In first version of a remote procedure and a version map that 

such implementations, it is incumbent for the RPC runtime maps the first version of the remote procedure to a second 

code on a server to detect the version of the interface used version of the remote procedure; and a request handler, 
by a client and direct any requests to appropriate versions of 65 residing in the first computer system and having access to 

routines on the server. However, if a client issues a request the remote procedure interface, that requests execution of 

using a version not supported by the server, the request fails. the remote procedure on a computer process on the second 
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computer system, wherein the request handler utilizes the and a server computer system in the distributed computer 

version map in the remote procedure interface lo request system of FIG. 1. 

execution of the second version of the remote procedure if pic. 3 is an exemplary remote procedure interface defined 

the computer process on the second computer system does in an interface definition language 0DL). 

not support the first version of the remote procedure. 5 ^ ^ extension of the remote procedure interface 

In accordance with a further aspect of the invention, there of FIG. 3, incorporating version mapping consistent with the 

is provided a method for requesting in a first computer principles of the invention. 

process a remote procedure to be executed by a second pj^, 5 ^ flowchart illiistrating the program flow for a 

computer process. The method mcludesttie steps of deter- referred HANDLE REQUEST routine execiiting on the 

mming in the first computer process whether the second 10 ^^.^^^ conptiler system of FIG. 2. 

computer process supports a first version of the remote , . _ or., 

procedure which is compatible with the first computer FIG^6 is a flowchart 

process; and if the second computer process does not MAP REQUEST routine of FIG. 5. 

support the first version of the remote procedure: mapping FIG. 7 is a flowchart illustrating the program flow of an 

the first version of the remote procedure to a second version 15 alternate HANDLE REQUEST routine to that of FIG. 5, 

of the remote procedure which is compatible with the second primarily for use in distributed computer systems not having 

computer process; and requesting the second computer network directories. 

process to execute the second version of the remote procc- FIG. 8 is a flowchart ill\istrating the program flow of the 

dure. RESEND REQUEST routine of FIG. 7. 

According to another aspect of the invention, a program ^° nFTAir Fn nF^PRlPnoN OF THF 

storage device is provided which readable by a first com- DETAILED DESCRIPTION OF THE 

puter process. The program storage device tangibly embod- PREFERRED EMBODIMENTS 

ies a program of instructions executable by the first com- Turning to the Drawing, wherein like numbers denote like 

puler process to request a remote procedure lo be executed parts throughout the several views, FIG. 1 shows an cxem- 

by a second computer process. Hie program includes a plary distributed computer system 1 consistent with the 

version map that maps a first version of a remote procedure principles of the invention. System 1 includes a plurality of 

to a second version of the remote procedure which is computer processes or systems (e.g., computer systems 10, 

compatible with the second computer process; and a request 20 and 60) coupled through a local area network (LAN) 5. 

handler that issues a request to execute the remote procedure Any number of computer systems may be coupled through 

on the second computer process, wherein the request handler network 5; however, for the purposes of illustration, only 

utilizes the version map lo issue a request lo execute the systems 10 and 60, which function as client systems, and 

second version of the remote procedure if the second com- system 20, which functions as a server system, are shown in 

puter process does not support the first version of the remote FIG. 1. 

procedure. piQ j illustrates a wide area network (WAN) 7 

According to a further aspect of the invention, a method between server system 20 and an additional server system 62 

is provided for transmitting a program product to a computer (which includes its own LAN 8 interconnecting the server to 

system. The method includes the steps of establishing a a client system 61). As is evident from this figure, enumer- 

connection with the computer system; and transmitting the able network connections, including LAN, WAN, global, 

program product to the computer system, the program and combinations thereof, with any number of client and 

product being executable by a first computer process on the server computer systems, may be envisioned in a distributed 

computer system to request execution of a remote procedure computer system. Thus, the invention should not be limited 

by a second computer process. The program product to any particular arrangement of computer systems across 

includes a version map that maps a first version of a remote any particular network configuration, 

procedure to a second version of the remote procedure Client system 10 includes a central processing unit (CPU) 

which is compatible with the second computer process; and a non-volatile program storage space such as read only 

a request handler that issues a request to execute the remote memory (ROM) 13, a workspace such as random access 

procedure on the second computer process, wherein the memory (RAM) 12, a mass storage device such as a hard 

request handler utilizes the version map to issue a request to disk 15, and a removable storage device such as a floppy 

execute the second version of the remote procedure if the drive 14, or alternatively a CD-ROM reader or tape drive, 

second computer process does not support the first version Similarly, server system 20 includes a CPU 21, a ROM 23, 

of the remote procedure. a RAM 22, a plurality of mass storage devices 24, and a 

These and other advantages and features, which charac- removable storage device 25. Systems 60, 61 and 62 may 

terize the invention, are set forth in the claims annexed also have a similar configurations. 

hereto and forming a fiirther part hereof. However, for a 55 jhe components shown for the above computer systems 

better understanding of the invention, and the advantages are generic to many types of computer systems. In some 

and objectives attained by its use, reference should be made cases, server systems 20 and 62 may be implemented in 

to the Drawing, and to the accompanying descriptive matter, i^^ger or more powerful systems than client systems 10, 60 

in which there are described preferred embodiments of the and 61. However, this is by no means indicative of all 

invention. distributed computer systems, and therefore it should be 

BRIEF DESCRiraON OF THE DRAWINGS appreciated that any of the above systems 10, 20 60, 61 and 

62 may be implemented m enumerable types oi computer 

FIG. 1 a functional block diagram illustrating the prin- systems having various configurations of hardware, 

ciple hardware components in a distributed computer system software, storage devices, and other peripheral components, 
consistent with the principles of the invention. 55 including personal computers, workstations, network 

FIG. 2 is a functional block diagram illustrating the servers, minicomputers, mainframe computers, 

principle software components of a client computer system supercomputers, etc. 
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FIG. 2 illustrates the software components of systems 10 process 38 executing on system 20 which is able to issue a 

and 20 functionally connected across network 5. The func- remote procedure request (designated by arrow 52 and 

tional hierarchy of system 10 includes an operating system utilizing CPIs 27) internally within system 20 to server 

16 operating on CPU 11, with various communications process 40 also resident on system 20. Accordingly, it will 

programming interfaces (CPIs) being designated at 17. 5 be appreciated that the terms "remote procedure" and 

Applications or computer processes, e.g., process 30, "remote procedure request" when used herein may relate to 

execute on top of this platform, and communication through client and server processes which either reside on the same 

network 5 is handled by a network interface 18. Similar to or different computer systems. In addition, although the 

system 10, the functional hierarchy of system 20 includes an much of the remaining discussion herein will focus spccifi- 

operating system 26 operating on CPU 21, communications caily on remote procedure calls (RPC's), one skilled in the 

programming interfaces (CPIs) 27, network interface 28 and art will appreciate that the discussion wiU also apply to 

processes 38 and 40. remote procedure requests between processes running on a 

Elements 16, 17 and 18 of system 10, as well as elements single computer system. 

26, 27 and 28 of system 20, may be implemented under Moreover, it will also be appreciated that while individual 

many different operating environments, including UNIX, ^5 computer processes will hereinafter be referred to as "cli- 

OS/400, MVS, MS-DOS, OS/2, Windows, and the Macin- ents'* or "servers", such processes may function as both 

tosh operating system, among others, with network commu- clients and servers in some applications, 

nication being handled in various network protocols such as Implementation of Remote Procedures in Distributed Com- 

IPX/SPX, TCP/IP, IBM Systems Network Architecture puter Systems 

(SNA), among others. The organization of the software As discussed above, remote procedure calls provide a 

within client and server systems such as systems 10 and 20 mechanism for allowing a program or computer process 

is well understood in the art, and will vary for different running on one computer system to call a subroutine which 

applications. is resident on a remote system. Thus, to illustrate the 

It will be appreciated that the various applications, workings of the preferred embcdiments of the invention, 

programs, computer processes and other supporting soft- 25 FIG. 2 shows one implementation of a distributed computer 

ware (e.g., the operating systems and interfaces) are resident system wherein client system 10 issues a remote procedure 

at different times on one or more "program storage devices." call (designated as 50) to server system 20. 

As used herein, the term "program storage device" may Consistent with the trend to implement modem computer 

include any device or apparatus capable of storing informa- programs using a structured, procedural approach, remote 

lion such as data or program code either in a volatile or 30 procedure calls are preferably implemented with only a 

non-volatile manner. Accordingly, a program storage device minimum of additional design and implementation by an 

may comprise memory devices such as RAMs, ROMs, applications programmer. In many distributed computer 

EPROMs, processor and cache memories, flash memories, systems, the primary implementation of remote procedure 

customized integrated circuits, etc., as well as fixed or calls is provided through four components which are illus- 

removable mass storage medias such as magnetic disks 35 trated in FIG. 2. First, a pair of "stub" components, e.g., 

(fixed or removable), CD-ROMs, magnetic tape, etc. In client stub 34 and server stub 44, implement the specific 

addition, it will be appreciated that the various applications, procedures which are to be sent across network 5. For 

programs, computer processes and other supporting soft- example, the RPC stubs "marshall" and "unmarshall" the 

ware (generically "program products") may be transferred or data comprising an RPC call and result to and from appro - 

downloaded to a computer system via network or modem in 40 priate data packets or streams suitable for being sent across 

lieu of being provided on a storage media such as a floppy the network. The RPC stubs may also process transmitted 

disk or CD-ROM, typically by first establishing a connec- and received data into compatible formats for their respec- 

tion between the computer system and a server-type tive systems. 

computer, and thereafter transmitting the program product to Another pair of procedures, e.g., client runtime 36 and 

the computer system. Thus, it will be appreciated that a 45 server mainline 42, are generic routines which typically 

"program storage device" may also include any of the handle many of the low level functions that are independent 

aforementioned memory and storage media of a server-type of particular RPC's. These functions may include, for 

computer (e.g., a bulletin board or ftp site) which downloads example, the actual transmission and receipt of data packets 

or transfers a program product to other computer systems across the network, among others. 

but does not actually execute the downloaded or transferred 50 One purpose of the aforementioned configuration is to 

program product. free an applications programmer from having to write much 

As discussed above, the preferred application of the of the specific code necessary to implement RPC's. Another 

invention is in the handling of remote procedure calls purpose of the configuration is to make RPC applications as 

between client and server computer processes resident on platform independent as possible. 

separate computer systems coupled through a network in a ss In general, to develop an RPC application, the desired 

distributed computer system. To illustrate this application, interface between a client and a server is defined using an 

FIG. 2 shows a client process 30 executing on system 10 interface definition language (IDL) which specifies the 

which issues a remote procedure call (designated by arrow desired remote procedures and the data structures, constants, 

50 which passes through the different low level functional and parameters required for implementation of the proce- 

components which generally handle the call) across network 60 dures. For example, FIG. 3 illustrates a typical RPC 

5 to a server process 40 executing on system 20. interface, which generally has flie form: 

Another preferred application of the invention is in ban- interface <int6rface name> version (<major> [:<minor>]) 

dling external or remote procedure requests between mul- { declarations } 

tiple computer processes operating on the same computer or Next, the interface file is compiled using an IDL compiler, 

processing system, e.g., separate applications or programs 65 Typically, compilation of the interface file results in four 

running concurrently on a multi-tasking computer system. files. On the client system, client stub and client header files 

To illustrate this application, FIG. 2 shows another client are generated. The client stub file is a compiled source file 
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which is linked with the client runtime code to provide what is meant is the interface provides a "prototypes" or 

access to the remote procedures. The client header is a other suitable templates which sets forth details such as 

header file containing prototypes, data structures and con- procedure name, expected sent and returned parameters, 

slants generated from the IDL file, and defining the format constants and data structures, etc. which permit a program or 

for calling the remote procedures in the client system. 5 routine running on the calling process to send an appropriate 

Similarly, two files are generated on the server system, remote procedure request that will be recognized and under- 
including a server stub file and a server header file. The stood by the remote computer process that actually executes 
server stub file is a compiled source file, linked with the the requested remote procedure. As such, it will also be 
server, that formats parameters prior to calling the actual appreciated that a remote procedure interface does not 
routines. The server header file is a header file containing the lO "exist" in a computer process in the format shown in FIGS, 
prototypes, data structures and constants generated from the 3 or 4, for example. Instead, the remote procedure interface 
IDL file, and defining the calling format of the routines of is primarily a tool or language which defines the protocol for 
the server. a programmer to use when writing the code which calls 

The resulting client and server stub files therefore gener- remote procedures from a calling computer process. The 

ally contain all the code necessary to collect all the client is remote procedure interface, however, may be considered to 

parameters and package them into a buffer, transmit the "exist" in an executing computer process during runtime, 

buffer across the network, unpack the buffer into a format the since the stub file in the computer process of the preferred 

server understands, call the routines on the server, and return embodiments contains the executable code that expects and 

any results to the client. The header files are for use by the implements a given remote procedure interface when receiv- 

application programmer when coding the application, but 20 ing and formatting remote procedure requests from a caUing 

they do not form components of the final executable apph- process. 

cation code. Implementation of Version Mapping into RFC Framework 

Once the aforementioned files have been compiled, the As discussed above, upgrading an RPC application 

client and server portions of the code are generated for the executing on multiple computers in a distributed computer 

RPC application. The client portion of code (e.g., main 25 system is often problematic due to a difficulty in upgrading 

program 32 of system 10) should be written to call the all client and server processes or components of the appli- 

desired remote procedures using the prototypes defined in cation. While conventional RPC implementations will allow 

the client header file. Similarly, the server portion of code a server to support multiple versions, these implementations 

should provide the actual remote procedure routines (e.g., do not support the case where an RPC client is upgraded to 

routines 46, 48 on system 20) that match the prototype in the 30 a newer version of an interface before the server is upgraded, 

server header file. The cUent and server header files need not This problem associated with conventional implementa- 

bc exactly the same due to type conversions, but they will tions is addressed herein by extending the interface defini- 

typically be very close. lion language to include the concept of a "version map" such 

To complete an RPC application, the application code is as version map 35 illustrated functionally in FIG. 2. A 
compiled and linked to the respective compiled stub files. 35 version map, which is preferably resident in the cUent stub 
The respective client and server object code are then ready (e.g., client stub 34 in system 10) provides a formal state- 
to be installed on suitable client and server computer sys- menl of how older versions of a procedure should be 
terns. handled, thereby freeing the caller of an RPC routine from 

A number of interface definition languages exist, e.g., for specifically addressing which version of the routine has to be 

the Open Systems Foundation Distributed Computing Envi- 4q called based upon the versions of the interface resident on 

ronment (OSF DCE), the Windows 95 and Windows NT the client and server computer systems, 

operating systems, the UNIX operating system, and the Sun Generally, the kinds of mapping that may be required 

Network File System (NFS), among others. Any interface between versions may include transforming parameters 

definition language may be modified to implement the prior to their being sent to a remote procedure, transforming 

invention as will be described below. One UNIX RPC 45 parameters that are returned from a remote procedure, 

interface is described, for example, in "UNIX System V providing default values for parameters that do not exist in 

Release 4 Programmer's Guide: Networking Interfaces" one version or the other, calling a substitute version of a 

available from UNIX Systems Laboratories. The OSF DCE procedure, and rejecting the call if certain conditions exist, 

RPC interface is described, for example, in "OSF DCE among others. In general, the version map may be consid- 

Application Development Guide" available from the Open 50 ered as a table that is generated as part of the client stub that 

Software Foundation. Other known systems and interfaces states, for each procedure, how to map that procedure to 

may also be used. Interfaces may be implemented in the C other versions of the interface. It will be appreciated that the 

programming language or one of its derivatives such as C++, concept of the version map can also be extended to other 

although other programming languages, including constmcts in an IDL definition, including objects and data 

FORTRAN, may also be used. 55 stnicturcs, for example. 

The above discussion pertaining to programming and Many different version mappings may be supported in an 

implementing distributed computer systems using remote interface consistent with the invention. As one example, in 

procedure calls is generally understood in the art. It will be system 1 of FIG. 2, version map 35 supports at least three 

appreciated that the particular implementations may vary for different "mappings" for a version of a remote procedijre in 

different systems. Furthermore, as the general operation of 60 the interface definition. The mappings are defined in an 

distributed computer systems and the like is generally extended version of a remote procedure interface, e.g., using 

known, the particular implementation of the RPC client and the statement: 

server code need not be discussed in greater detail for a versionmap (<version> <mapping>); 

complete understanding of the invention. A first mapping is a direct mapping, e.g., using the 

Moreover, it will be appreciated that, in preferred embodi- 65 keyword "DIRECT" (such as for the version 1.1 mapping of 

ments of the invention, a remote procedure interface is Routine C in version map 35). The use of this keyword 

utilized to "define" the remote procedures. By "define", indicates that the procedure can be mapped directly between 
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the two versions with no conversion. The runtime simply To implement version mapping in an RPC application, the 

calls the routine in the mapped version without modification. client-side request handling, performed in the client stub, 

A second mapping is useful when two versions of a must be modified from conventional runtime routines. In 

procedure differ only in the numbers and/or names of particular, request handling requires that (1) the version of 

parameters. This mapping may be implemented, for 5 the server be determined, and (2) any mapping to earlier 

example, using the keyword "BYNAME" (such as for the versions be performed, prior to issuing the remote procedure 

version 1 .0 mapping of Routine B in version map 35). Under call over the network. 

this mapping, a procedure can be mapped simply by match- In general there are three primary ways that a client can 

ing parameters by name. Unmatched parameters may default locate a server on a network. First, the client can explicitly 

to a default value such as zero. be told the name and/or address of the server (e.g., via a 

A third mapping may be useful when greater modifica- parameter to the procedure, an environment variable, or an 

tions are required to execute a procedure in an earlier external configuration file). Second, the client and server can 

version. In this case, the keyword may be the name of a locate each other via some broadcast mechanism (e.g., the 

mapping procedure (such as the CallRoutineDVl( ) routine IPX SAP broadcasts). This can happen in either direction, 

for the version 1.0 mapping for Routine A in version map with the client or server broadcasting its existence, and the 

35). Under this mapping, the mapping procedure must be other responding. Third, the client can look up the server in 

separately coded to perform any of the necessary functions some form of network directory (e.g., the DCE cell directory 

required to call the earlier version procedure. This may service). Typically, with the first two ways, the client has 

include, for example, calling a substitute remote procedure, very little knowledge about the server, other than its name 

adding or removing parameters, setting specific defaults for and address. With the third way, however, the client can 

parameters, or handling any other situation which requires 20 generally obtain additional information from the server, such 

more modification than simply matching parameters by as exactly what interfaces and protocols it supports, 

name. The manner in which requests are handled during RPC 

In addition to the above mappings, an additional keyword, runtime may be different for systems that support a network 

such as "NOMAP", may be used to indicate when no directory as opposed to those that do not. This is because 

mapping exists for a particular version (such as the version ^5 version mapping needs to be determined prior to conversion 

1.0 map for Routine C in version map 35). In this case, the parameters and marshalling of data in preparation for 

RPC runtime may indicate a failed call due to the mability sending an RPC request over a network. If a directory exists, 

to map a call to the earlier routine . the client can typically determine the version of the server 

Afailed call may also be mdicated by the RPC nintime if ^^^^^ ^^^^ However, if no directory exists, the data may 

a particular version is no supported by the mterface (i.e., marshalled and the call made before determining that the 

when no keywords are found in the version map for a . „ . c j • » • n 

particular version). Alternatively, the RPC runtir^e may ^^^S ^t'''^'' "^"^"'uT^ n ^ }^ 

attempt to handle earlier versions in different manners, e.g., ^^^^^^^^^^^ remarshalled and the call reissued, 

by using the mapping from the earliest supported version for ^IG. 5 shows a flow chart of a preferred request handler, 

the interface. routine HANDLE REQUEST 100, for use on distributed 

As another example, FIG. 4 shows an extended RPC 35 computer systems which utilize network directories. This 

interface, which has been upgraded from the interface shown routine represents typical runtime processing of a remote 

in FIG. 3 to include a version 2.0 interface. Each remote procedure request in client stub file 34 of process 30. 

procedure listed in the version 2.0 interface includes a Routine 100 can generally be segregated into a mapper with 

"versionmap( )" parameter to map each routine to prior a mapping function (blocks 102-108 and 120) and a 

versions. 40 requester with a requesting function (blocks 110-114). 

In this example, longer user names (previously 20, now As for the mapping function, routine 100 begins in block 

30) are supported in version 2.0, and a new function 102 by attempting to locate the destination server, typically 

testUID( ) is defined. Each defined procedure in the new by accessing a network directory in a manner known in the 

version of the interface states how to map back to the art. If the destination server is not found, the remote proce- 

previous version. Given the longer user names, the getUser( 45 dure call fails, and control passes to block 116 to indicate the 

) and setuser( ) functions are mapped by name using the failure prior to returning to the main code, or calling routine, 

keyword "BYNAME". The g6tUlDfromName( ) and If, however, the server is found, the version of the server is 

getNamefromUID( ) functions can be called without any determined in block 104, again by accessing the network 

parameter mapping, as denoted by the keyword "DIRECT". directory. Next, in block 106, routine 100 determines 

The testUID( ) function cannot be mapped directly; 50 whether version mapping is required, generally by compar- 

however, a short procedure may be written to map this to ing the version of the server with the version of the client 

some other call. This short procedure is identified by the upon which the routine is running. 

procedure name mapTestUIDProc. This procedure may per- If no mapping is required, which typically occurs when 

form any tasks necessary to reformat the call to support a the server supports the version of the client, control passes 

prior version, such as calling a substitute procedure, setting 5S to the requesting function of routine 100, specifically to 

defaults, adding or removing parameters, etc. For example, block 110 to "marshall" the request. In marshalling the 

the getNamefromUID( ) routine could instead be called to request, the pertinent information required to issue the 

test if a UID exists. However, since such a procedure would remote procedure request is gathered and formatted into a 

be specific to the particular remote procedure involved, it is stream of bytes that can be transmitted across the network, 

not discussed separately herein. 60 Then, in block 112, the marshalled request data is sent to the 

It will be appreciated that various alternative mappings, server across the network, and the routine waits until a 

which perform additional or different mapping functions, response is received. Next, in block 114, the response is 

may be incorporated into the extended interface within the "unmarshalled", which is essentially the reverse of 

scope of the present invention. Therefore, the invention marshalling, to obtain the resulting information forwarded 

should not be limited to the particular mappings and key- 65 from the server in response to the remote producer request, 

words utilized in the preferred embodiments disclosed Once the response has been unmarshalled, the routine ter- 

herein. minates to allow the main code to process the response. 
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The response from a remote procedure may consist only If the version map returns a keyword of "NO MAP", block 
of an acknowledgment of the request, or may include data 130 passes control to block 132 to indicate a failed call, prior 
which was requested during the remote procedure. The to terminating the HANDLE REQUEST routine and return- 
operations of marshalling, unmarshalling, sending and ing to the main code. This is indicative of a procedure which 
receiving data across a network in a distributed computer 5 does not have a counterpart on the server version, and which 
system are generally understood in the art. Moreover, it will therefore may not be called by the client, 
be appreciated that additional formatting or other transfer- Finally, if the keyword return from the version map is 
raation of data cither in the request or in the response may "DIRECT", block 134 merely returns control to the 
be required such that both client and server obtain data from HANDLE REQUEST routine (specifically block 110 of 
the other in a compatible format. lO FIG. 5) to continue processing of the request. When such a 

Returning to block 106, if it is determined that version keyword is encountered, no mapping is required, and the 

mapping is required, e.g., because the server does not request may be made with no modification to accommodate 

support the version of the client issuing the remote proce- the earlier server version. 

dure request, control passes to block 108 to determine if If block 134 does not receive a "DIRECT" keyword, the 

version mapping is possible. In this block, the version of the 15 system has received a keyword which is not recognized, 

server is compared against the different versions to which Accordingly, control passes to block 132 to indicate a failed 

version mapping is defined in the remote procedure interface call prior to returning control to the main code, 

for the client. For example, some interfaces may be made In the situation where a network directory is not available 

backward-compatible only for a few prior versions, e.g., if in the distributed computer system, an alternative HANDLE 

the changes between the current version and a much earlier 20 REQUEST routine 150, also including a mapper with a 

version have become so significant that the functionality of mapping function (blocks 120 and 152-156) and a requester 

the much earlier version is insufficient for clients running the with a first requesting function (blocks 158-164), is 

current version. In such a case, mapping an interface to the executed as shown in FIG. 7. In this routine, the client 

much earlier version is unnecessary. Therefore, control is computer process preferably supports a "cache" or table of 

diverted in this situation to block 116 to indicate a failed call 25 servers and their versions so that at most one incorrect 

prior to returning to the main code. version call is made to a given server before the correct 

If, on the other hand, the version of the server is supported server version is found. In essence, the client computer 

by the client, control passes to block 120 to call a separate process builds a local directory of servers and their sup- 

MAP REQUEST routine 120 which handles the mapping ported versions, rather than relying on a separate network 

prior to the executing the requesting function of blocks 110, 30 directory to provide this information. 

112 and 114. As shown in FIG, 7, routine 150 begins with a mapping 

FIG. 6 illustrates MAP REQUEST routine 120 in greater function at block 152 by checking the server version cache 

detail. Essentially, this routine first performs a keyword internal to the client. Block 154 then determines if version 

determining function in block 121 by accessing the mapping is required. If the server is found in the cache and 

versionmap( ) parameter in the client interface (specifically 35 it is determined that the version supported by the server 

in the version map or table in the client stub file) for the requires mapping from the client version, control passes to 

particular procedure defined in the remote procedure inter- block 156 to determine if the server version is supported by 

face. the client. If the mapping is not supported, control passes to 

Based upon the keyword returned from the version map block 160 to indicate a failed call prior to returning control 

for the particular version of the server, blocks 122, 126, 130 40 to the main code. 

and 134 divert control to separately handle the different Ontheother hand, ifthe server version is supported by the 

mappings. Alternatively, blocks 122, 126, 130 and 134 may client, control passes to block 120 to call the MAP 

be replaced with a single "case" function as is generally REQUEST routine illustrated in FIG. 6. Then, after the 

known in the art. request has been mapped in block 120, control passes to the 

If the version map for the particular routine and version of 45 first requesting function of routine 150, where block 158 

the server points to a user-defined procedure (e.g., the marshalls the request. Block 162 then sends the marshalled 

version 1 .0 mapping for Routine Ain FIG. 2, or the mapping request to the server and waits to receive a response thereto, 

for the testUID( ) routine of FIG. 4), control is passed to The response is then unmarshalled in block 164. 

block 124 to call the specific procedure referred to in the Next, block 166 determines whether the server supports 

version map, prior to terminating the HANDLE REQUEST 50 the client version of the RPC interface. Generally, block 166 

routine 100. It will be appreciated that in many instances an will indicate that the server supports the client version if a 

alternative remote procedure may be called, in which case suitable or expected response is returned from the server in 

the HANDLE REQUEST routine 100 may be called recur- reply to the remote procedure request, 

sively by this user-defined procedure. On the other hand, if the server does not support the client 

If, on the other hand, the version map returns a 55 version, the response to the request which is returned by the 

"BYNAME" keyword, control is passed to block 128 by server will generally indicate a failed request, and preferably 

block 126 to map the various parameters to the format include an indication of the current version of the server 

expected by the server. This essentially results in the original (e.g., through returning a list of supported versions for the 

parameters for the remote procedure request being replaced server). On the other hand, if no indication of the versions 

with the new parameters that are specific to the server 60 supported by the server is provided, the chent may try all of 

version. In addition, if a field in the new format its supported versions until a suitable response is received • 

(corresponding to the server version) docs not have a from the server, although such an implementation would not 

counterpart in the client version of the interface, this field or be as efficient as others. 

parameter will default to zero. After completion of the field In the case that the server doesn't support the client 

mapping, control then returns to the HANDLE REQUEST 65 version, a separate routine, RESEND REQUEST routine 

routine to continue processing of the request in block 110 of 170, is called by block 166 prior to returning control to the 

FIG. 5. main code and terminating the HANDLE REQUEST rou- 
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tine. Routine 170 forms a second request function for the 
requester of routine 150. 

The RESEND REQUEST routine 170 is illustrated in 
greater detail in FIG, 8. First in this routine, block 172 adds 
the server to the version cache, as well as the supported $ 
version or versions supported by the server. In some 
instances, e.g., if the server has been upgraded since the last 
access by this client, the server may already be present in the 
cache, whereby only an update of the supported versions for 
the server is required. 

Next, in block 174, the supported versions of the server 
are compared with the version of the client to determine 
whether it is possible to map the request to a version 
supported by the server. If this is not possible, control is 
diverted to block 176 to indicate a failed call and to return 
control to the HANDLE REQUEST routine. If, however, a 
version of the server is supported by the chent, control 
passes to block 120 to map the request consistent with the 
version map of the client. Next, in blocks 178, 180 and 182, 
the request is marshalled and sent to the server, and a 
response is received and unmarshalled, in the manner 20 
described above. Upon completion of block 182, the routine 
terminates and returns to HANDLE REQUEST routine 150. 

Returning to block 154 of FIG. 7, in the event that a server 
is not recognized in the server cache for the chent, block 154 
diverts control to block 158 without attempting to map the 25 
request to a prior version. Then, blocks 158, 162 and 164 are 
executed as described above to attempt to issue the request. 
In this case, the routine does not know which versions are 
supported by the server. Thus, this initial request serves 
merely the function of obtaining the supported versions of 3Q 
the server so that the request may be resent in a proper 
manner (and so that the server version cache can be updated) 
in RESEND REQUEST routine 170. 

Various changes and modifications may be made to the 
preferred embodiments without departing from the spirit and 35 
scope of the invention. For example, as discussed above, 
different manners of detecting and maintaining a register of 
servers and supported versions may be used. Moreover, 
various degrees of mapping between versions may be sup- 
ported above and beyond the keywords supported by the 
preferred embodiment. Other modifications will be apparent 
to one skilled in the art. 

Therefore, the invention provides substantial benefits by 
virtue of the flexible and reliable manner in which multiple 
versions of remote procedure interfaces are permitted to 
coexist in a distributed computer system. As one skilled in 
the art will appreciate that oliier modifications may be made 
to the preferred embodiments consistent with the invention, 
the invention therefore lies in the claims hereinafter 
appended. 5q 

What is claimed is: 

1. A computer system comprising a client computer 
process for requesting a remote procedure to be executed by 
a server computer process external to the client computer 
process, the client computer process supporting a first ver- 55 
sion of the remote procedure and the server computer 
process supporting a second version of the remote 
procedure, the client computer process comprising: 

(a) a mapper that maps the first version of the remote 
procedure to the second version of the remote proce- 
dure if the server computer process does not support the 
first version of the remote procedure; 

(b) a requester, coupled to the mapper, that requests the 
server computer process to execute the second version 

of the remote procedure; and 65 

(c) a version map that maps the first version of the remote 
procedure to the second version of the remote 
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procedure, wherein the version map comprises a key- 
word indexed by a version number, wherein the key- 
word is selected from the group consisting of a direct 
keyword, a byname keyword, a nomap keyword, and a 
user-defined procedure keyword, wherein the mapper 
determines the keyword in the version map correspond- 
ing to the second version of the remote procedure, and 
wherein: 

(1) if the keyword is a direct keyword, the mapper 
directly maps the first version of the remote proce- 
dure to the second version; 

(2) if the keyword is a byname keyword, the mapper 
maps parameters of the remote procedure by name 
from the first version to the second version; 

(3) if the keyword is a nomap keyword, the mapper 
returns a failed request indication; and 

(4) if the keyword is a user-defined procedure keyword, 
the mapper calls the user-defined procedure. 

2. The computer system of claim 1, wherein the server 
computer process is resident on a second computer system 
coupled to the first computer system through a network, and 
wherein the requester issues a remote procedure call across 
the network to execute the remote procedure. 

3. The computer system of claim 1, wherein the mapper 
further determines the version of the server computer pro- 
cess. 

4. The computer system of claim 1, further comprising a 
client stub file and a client header file, wherein the client stub 
file is an executable file including the mapper, the version 
map and the requester, and wherein the client header file 
defines a prototype of the remote procedure for calling by 
the client computer process. 

5. The computer system of claim 3, wherein the requester 
further receives a response from the server computer process 
in reply to the remote procedure. 

6. A distributed computer system, comprising: 

(a) first and second computer systems coupled through a 
network; 

(b) a remote procedure interface residing in the first 
computer system, the remote procedure interface defin- 
ing a first version of a remote procedure and a version 
map that maps the first version of the remote procedure 
to a second version of the remote procedure; and 

(c) a request handler, residing in the first computer system 
and having access to the remote procedure interface, 
that requests execution of the remote procedure on a 
computer process on the second computer system, 
wherein the request handler utilizes the version map in 
the remote procedure interface to request execution of 
the second version of the remote procedure if the 
computer process on the second computer system does 
not support the first version of the remote procedure; 

wherein the request handler determines the version of the 
computer process on the second computer system and 
maps the first version of the remote procedure to the 
second version of the remote procedure if the computer 
process on the second computer system does not sup- 
port the first version of the remote procedure; 

wherein the remote procedure interface is defined in an 
interface definition language, wherein the version map 
comprises a keyword indexed by a version number, 
wherein the keyword is selected from the group con- 
sisting of a direct keyword, a byname keyword, a 
nomap keyword, and a user-defined procedure 
keyword, wherein the request handler accesses the 
version map to determine the keyword in the version 
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map corresponding to the second version of the remote 
procedure; and wherein: 

(a) if the keyword is a direct keyword, the request 
handler directly maps the first version of the remote 
procedure to the second version; 5 

(b) if the keyword is a byname keyword, the request 
handler maps parameters of the remote procedure by 
name from the first version to the second version; 

(c) if the keyword is a nomap keyword, the request 
handler returns a failed request indication; and lO 

(d) if the keyword is a user-defined procedure keyword, 
the request handler calls the user-defined procedure. 

7. The distributed computer system of claim 6, wherein 
the network is selected from the group consisting of a local 
area network, a wide area network, a global network, and 15 
combinations thereof. 

8. The distributed computer system of claim 6, further 
comprising a network directory indicating at least one 
supported version of the remote procedure for the computer 
process on the second computer system, and wherein the 20 
request handler accesses the network directory to determine 
the version of the computer process on the second computer 
system. 

9. The distributed computer system of claim 6. wherein 
the request handler further comprises a server version cache 25 
indicating at least one supported version of the remote 
procedure for the computer process on the second computer 
system, wherein the request handler requests execution of 
the first version of the remote procedure if the computer 
process on the second computer system is not in the server 30 
version cache, and wherein, when the computer process on 
the second computer system indicates that the first version of 
the computer process is not supported in response to the first 
request means, the request handler adds the computer pro- 
cess on the second computer system to the server version 35 
cache; and requests execution of the second version of the 
remote procedure by the computer process on the second 
computer system. 

10. The distributed computer system of claim 6, wherein 
the request handler additionally marshalls a request for the 4o 
remote procedure into a request data stream; transmits the 
request data stream over the network to the second computer 
system; receives a response data stream over the network 
from the second computer system; and unmarshalls a 
response from the response data stream. 45 

11. A computer implemented method of requesting in a 
first computer process a remote procedure to be executed by 
a second computer process, the method comprising the steps 
of: 

(a) determining in the first computer process whether the 50 
second computer process supports a first version of the 
remote procedure which is compatible with the first 
computer process; and 

(b) if the second computer process does not support the 
first version of the remote procedure: 

(i) mapping the first version of the remote procedure to 
a second version of the remote procedure which is 
compatible with the second computer process; and 



112 

16 

(ii) requesting the second computer process to execute 
the second version of the remote procedure; 
wherein the mapping step includes the step of accessing 
a version map which maps the first version of the 
remote procedure to the second version of the remote 
procedure; 

wherein the version map comprises a keyword indexed by 
a version number, wherein the keyword is selected 
from the group consisting of a direct keyword, a 
byname keyword, a nomap keyword, and a user- 
defined procedure keyword, wherein the mapping step 
further includes the steps of: 

(a) determining the keyword in the version map corre- 
sponding to the second version of the remote proce- 
dure; 

(b) if the keyword is a direct keyword, directly mapping 
the first version of the remote procedure to the 
second version; 

(c) if the keyword is a byname keyword, mapping 
parameters of the remote procedure by name from 
the first version to the second version; 

(d) if the keyword is a nomap keyword, returning a 
failed request indication; and 

(e) if the keyword is a user-defined procedure keyword. 
caUing the user-defined procedure. 

12. The method of claim 11, wherein the determining step 
includes the step of accessing a network directory to deter- 
mine the version of the computer process on the second 
computer system. 

13. The method of claim 11, wherein the determining step 
includes the step of accessing a server version cache to 
determine supported versions of the remote procedure for 
the computer process on the second computer system, and 
wherein the requesting step includes the steps of: 

(a) requesting execution of the first version of the remote 
procedure if the computer process on the second com- 
puter system is not in the server version cache; and 

(b) if the computer process on the second computer 
system indicates that the first version of the computer 
process is not supported in response to the first request 
means: 

(1) adding the computer process on the second com- 
puter system to the server version cache; and 

(2) requesting execution of the second version of the 
remote procedure by the computer process on the 
second computer system. 

14. The method of claim 11, further comprising the steps 

of: 

(a) marshalling a request for the remote procedure into a 
request data stream; 

(b) transmitting the request data stream over the network 
to the second computer system; 

(c) receiving a response data stream over the network 
from the second computer system; and 

(d) unmarshalling a response from the response data 
stream. 
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